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BACKGROUND 

Field of Invention 

This invention relates to the field of a computer software, and particularly, 

the detection of attachment of peripheral devices to a host system. 

10 Copyright and Trademark Notice 

A portion of the disclosure of this patent document contains material which 

is subject to copyright protection. The owner has no objection to the facsimile 

reproduction by any one of the patent document or the patent disclosure, as it 

appears in the Patent and Trademark Office patent file or records, but otherwise 

1 5 reserves all copyrights whatsoever. 

Certain marks referenced herein may be registered trademarks of third 
parties affiliated or unaffiliated with the applicant or the assignee. Use of these 
marks is for the purpose of providing an enabling disclosure by way of example 
20 and shall not be construed to limit the scope of this invention to material strictly 
associated with such marks. 
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Related Art 

Advancements in computer technology have lead to development of smart 
devices also referred to as embedded systems. Embedded systems are specialized 
computers used to control devices such as automobiles, home and office 

5 appliances, and handheld units of all kinds. Generally, in embedded systems, the 
operating system and application functions are combined in the same program. An 
embedded system typically only performs a fixed and specific set of functions 
programmed into a non-volatile memory (e.g., ROM, flash memory, etc.) in 
contrast to a general-purpose computing machine that can be programmed to 

10 perform many different functions. As such, most embedded systems have limited 
resources that support only specific functions. Most embedded systems do not 
support storage of large volumes of data as a general-purpose computer does. 

On occasions, it is desirable to attach peripheral devices to embedded 
15 systems for additional functionality. For example, some portable handheld 
computing systems such as Personal Digital Assistants (PDA's) are now designed 
to receive attachment modules that can convert or modify the system's operation. 
For example, Visor™, an electronic PDA from Handspring Corporation, Mountain 
View, California, accepts various modules that allow the attachment of peripheral 
20 devices such as a digital camera, modem, or other electronic devices. 

Once a peripheral device is attached to an embedded device, hereinafter 
also referred to as a host system, it is necessary for the host system to control and 
communicate with the peripheral device. Typically, the host's ability to 
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communicate and control a device is possible through the installation of a device 
driver for that device. A device driver is program routine (software) that provides 
for means of communication between a peripheral device and the system software 
(e.g., the operating system) running on the host system. A device driver is written 
5 by programmers who have detailed knowledge of the peripheral device's command 
language and characteristics as well as the system software that runs on the host 
system. As such, a device driver for a specific device dictates the precise machine 
language necessary to perform the functions requested by system software 
controlling the device. 

10 

Certain fundamental drivers that manage the essential components of a host 
system are included in the system BIOS (Basic Input Output System). BIOS 
includes a set of routines, which is stored on a memory chip and provides an 
interface between the operating system and the hardware. However, when a new 
15 hardware device is added or attached to the system, the driver for that device needs 
to be loaded in order to control the operation of the device. After the driver is 
loaded, the operating system running on the host system communicates with the 
driver and the driver communicates with the device. 

20 There are several problems associated with device drivers. First, if a device 

driver for a device is not available on the host system, then it has to be installed by 
the user. Typically, many devices are sold with portable data storage mediums 
such as CD ROMs or floppy disks that include the device driver. Thus, a host 
system needs to include mechanisms such as a CD ROM or floppy drive to read 
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and install the driver. Second, if the device is replaced with a newer model or a 
newer version of the driver is available, the driver needs to be updated. Third, 
installation of device drivers requires large amounts of data storage space, if the 
host system is to support a variety of peripheral devices. 

5 

As it can be imagined, the above problems can substantially limit the 
potential for an embedded system to act as a host, because embedded systems do 
not have the same storage space capabilities or mechanisms available in personal 
computers. For example, a PDA does not have a floppy or CD ROM drive and 

10 therefore cannot load a device driver from a floppy or CD ROM. Some device 
manufacturers provide the device drivers for download over the Internet. 
However, many embedded devices (e.g., set-top boxes, Internet gateways, DSL 
providers) may not be equipped with user interface tools to efficiently allow a user 
to navigate the Internet to find and install the appropriate driver or such drivers 

15 may not be generally available. Further, as stated earlier, most embedded systems 
lack sufficient memory or data storage space to support the storage of many device 
drivers for various devices. 

Another problem with the use of device drivers is the inconvenience 
20 associated with the installation of a driver. In order to use and operate a new 
device, a user has to manually search for and install the driver and further 
configure the host to recognize the driver and the device, thus requiring a user to 
wait and perform certain chores before he or she can even use the device. To 
overcome this problem, a number of solutions have been implemented. For 
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example, the Plug and Play™ communication protocol is a standard used in the 
design of personal computer expansion boards, developed by Intel® Corporation, 
Santa Clara, California. Plug and Play is supported directly in Windows 
95/98/2000, the operating system developed for personal computers by Microsoft® 
5 Corporation, Redmond, Washington. Using this technology, once a device is 
attached to the system, system settings (e.g., IRQ and DMA settings) and I/O and 
memory addresses self configure to recognize a newly attached device. This 
eliminates the frustration of configuring the system when adding new peripherals 
that comply with the requirements of the Plug and Play communication protocol. 

10 

In addition to the Plug and Play standard, a distributed computing 
environment from Sun Microsystems® Corporation, Mountain View, California, 
called Jini™ is available in which peripheral devices can be plugged into a network 
environment and automatically offer their services and make use of other services 
15 on the network. Jini turns peripherals into services, so that when a disk drive, for 
example, is plugged in to the network, it becomes a storage service rather than just 
another disk drive. Devices that attach to a Jini system must also comport with the 
requirements of the Jini system. 

20 The above-described protocols and systems are designed and developed for 

computing systems that meet the memory and data storage requirements needed to 
support sophisticated operations and functions performed by the hardware and/or 
software in such systems. For example, implementing Plug and Play requires a 
system BIOS on the motherboard that supports Plug and Play as well as Plug and 
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Play expansion cards that are typically not available in embedded systems. Jini 
provides a Java-based distributed computing network that requires a participating 
host to incorporate a Java virtual machine, and often a Java browser, which are 
memory intensive and not suited for the limited operating environment available in 
5 embedded systems. 

The present inventor therefore has determined that it would be useful to be 
able to automatically load a device driver for a peripheral device on an embedded 
host system, upon attachment of the device to the system. It would be further 
10 useful to display certain related information to a user based on information 
collected about the attached device and the host system. 

The present invention and its advantages over the prior art would be better 
appreciated and understood by the following review of the currently available 
15 device driver architectures in conjunction with the Universal Serial Bus (USB) 
interface mechanism. 

Device Driver Architectures 

There are essentially two types of device driver architectures, monolithic 
and layered. A monolithic driver is essentially a piece of system software designed 
20 specifically for the control and communication for a particular device or portion of 
hardware. The functionality provided by the monolithic driver is typically tied 
very closely to the particular hardware that the software drives. In comparison, the 
layered driver usually provides general support for a particular set of hardware 
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interfaces. The software architecture in a layered driver, as the name describes, 
provides various layers of interfaces. As the layers move away from the specific 
hardware, they move from broad to narrow in functionality. 

5 While the two driver architectures implement the same functionality, the 

layered architecture offers more flexibility for supporting different devices and 
different hardware platforms as future requirements dictate. The monolithic driver, 
for example, supports a USB Video Camera in the same way the layered driver 
can, however, if a USB mouse needed to also be supported, a separate monolithic 
10 USB mouse driver would be needed. In the case of the layered driver, only a high 
level driver for the mouse is needed. The other layers, namely the USB protocol 
support and low-level hardware layer could be reused. In addition, each layer can 
be written such that it can support multiple layers, thus the USB mouse and USB 
camera can utilize the lower USB protocol support layer simultaneously. 

15 

Driver development has migrated more and more towards layered software 
architectures as interfaces such as IEEE 1394 and USB have lend themselves to be 
better utilized if a layered architecture is implemented. 
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SUMMARY 

One or more embodiments of the invention are directed to a system and 
method for automatically detecting the attachment of a peripheral device to a host 
system and configuring the host system for communication with the peripheral 
5 device. In accordance with an aspect of the invention, when a peripheral device is 
attached to the host system, the host detects the attachment of the device. The host 
can be an embedded system such as a set-top box, a mobile phone, a personal 
digital assistant (PDA), or any other type of computing system. The peripheral 
device can be a modem, a digital camera, a microphone, or any other device that 
10 can be used in conjunction with the host. 

In order to communicate and control the operation of the peripheral device, 
the host system needs special software to interact with the device in a specific 
command language that is compatible with the requirements of the device. Special 

15 software for communicating with peripheral devices is typically provided in form 
of a code routine known as a device driver. If the device driver is locally available, 
then host system installs and loads the device driver. By means of the device 
driver, the host system communicates with and controls the peripheral device. If 
the device driver is not locally present, then the host system establishes a 

20 connection with a server system through a network connection. Alternatively, 
even if a device driver is locally present, the host system may query the server for a 
more recent driver. The server system can be a remote server system accessible 
via the Internet or it can be a server in a local area network. 
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The server includes a database that includes either the device driver needed 
for operation of the device, or one or more references to locations where the device 
driver may be found. Once the appropriate device driver is located, the device 
driver is forwarded to the host system. The host receives the device driver, installs, 
5 and loads it into memory. The device driver is then integrated into the host's 
system software, so that the host can communicate with and control the peripheral 
device. 

One or more embodiments of the invention are directed to an on-line 
10 system that provides directed information delivery to targeted audience who use a 
particular peripheral device in conjunction with a host system connected to a 
communication network. In accordance with one aspect of the invention, 
advertisements or other relevant information about a peripheral device or a host 
system are displayed to a user, when the host system detects the attachment of the 
15 device. 
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BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 illustrates a client-server architecture, according to one or more 
embodiments of the current invention. 

5 FIG. 2 illustrates a flow diagram of a method of attaching a peripheral 

device to a host system, in accordance with one or more embodiments of the 
system. 

FIG. 3A illustrates an example of the components of the host or server 
10 system of this invention, in accordance with one or more embodiments. 

FIG. 3B illustrates computer software suited for managing and directing the 
operation of the system hardware environment illustrated in FIG. 3A. 

15 FIG. 4 illustrates the host system including a hub to which a peripheral 

device attaches. 

FIG. 5 illustrates a flow diagram of a method of detecting the attachment of 
a peripheral device to a host system. 

20 

FIG. 6 illustrates a method of locating and loading control software on host 
110 after host system been notified of the attachment of the peripheral device. 
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FIG. 7 illustrates a method of directed information delivery to targeted 
audience who use a particular peripheral device in conjunction with a host system 
attached to a communication network. 
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DETAILED DESCRIPTION 

The invention is directed to a method and system for automatically 
configuring a peripheral device attached to a host system. Embodiments of the 
invention are described by way of example as applicable to devices attached to a 
host system via a Universal Serial Bus® (USB). The examples provided here are 
not to be construed to limit the application of the invention to the USB 
architecture, however. The invention is applicable to any interface that provides 
for the attachment of a device to a host system, including wireless connections. 

In the following, numerous specific details are set forth to provide a 
thorough description of various embodiments of the invention. It is apparent, 
however, to one skilled in the art that certain embodiments of the invention may be 
practiced without these specific details or with some variations in detail. In some 
instances, well-known features not pertinent to the novelty of the system are 
described in less detail so as not to obscure the more relevant aspects of the 
invention. 

System Architecture 

One or more embodiments of the invention are directed to a system and 
method for automatically detecting the attachment of a peripheral device to a 
computing system and configuring the computing system for communication with 
the peripheral device. Typically, a computing system is composed of two distinct 
environments, a software environment and a hardware environment. The hardware 
environment, as it is discussed in further detail below, includes the machinery and 
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equipment that provide an execution environment for the software. On the other 
hand, the software provides the execution instructions for the hardware. 

In operation, a computing system needs both hardware and software to 
5 function. The software can be divided into two major classes including system 
software and application software. System software includes control programs, 
such as the operating system (OS) and information management systems, that 
instruct the hardware how to function and process information. An example of 
system software is Microsoft Windows 2000® operating system generally used for 
1 0 managing the operation of personal computers. 

Application software is a program that performs a specific task. In 
embodiments of the invention, system and application software are implemented to 
automatically detect the attachment of a peripheral device to a host system and 
15 configures the host system to control and operate the device. In certain 
embodiments of the invention, system and application software may be 
implemented as firmware in a category of memory chips such as ROM, PROM, 
EPROM and EEPROM that hold their content without electrical power. 

20 FIG. 1 illustrates a system architecture, according to one or more 

embodiments of the current invention, comprising a host system 110 attached to a 
server system 130. In some embodiments, host system 110 communicates with 
server system 130 through network connection 150 to retrieve configuration 
information associated with peripheral device 120. Server system 130 includes or 
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is in communication with database 140. Database 140 includes configuration 
information (e.g., device drivers) that can be forwarded through network 
connection 150 to host system 110. 

5 Host system 1 10 and server system 130 may be connected in a local area 

network (LAN), or alternatively in a wide area network (WAN) or worldwide 
network, such as the Internet. As it is further discussed below, host and server 
systems 110 and 130 include hardware and software components and system 
architectures suited for operation of application software of this system. FIG. 2 
10 illustrates a flow diagram of a method of attaching peripheral device 120 to host 
system 110. 

According to one or more embodiments, at step 210 peripheral device 120 
is attached to host system 110. Host 110 can be a general purpose computing 

1 5 system such as a desktop or laptop computer. In other embodiments, host 1 10 is an 
embedded system such as a set-top box or a personal digital assistant (PDA). 
Peripheral device 120 can be a modem, a digital camera, a microphone, or any 
other device that can be used in conjunction with host 1 10. Embodiments of the 
invention include an interface that allows for the attachment of device 120 to host 

20 110. 

At step 220, host 110 detects the attachment of device 120. In order to 
communicate and control the operation of device 120, host 110 needs special 
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software to interact with device 120 in a specific command language that is 
compatible with the requirements of device 120. Special software for 
communicating with peripheral devices is typically provided in form of a code 
routine as described above also known as a device driver. The device driver 
5 provides for host 1 10's system software to communicate with device 120. At step 
230, host 110 queries the system to determine whether the device driver for the 
particular device is present locally. The driver is present locally if it is stored on 
host system 1 10 or is provided by device 120. 

10 If the device driver is locally available, then at step 240 host system 110 

installs and loads the device driver. By means of the device driver, host system 
110 communicates with and controls device 120. If the device driver is not locally 
present, or in search of a newer version of the device driver, host system 110 
establishes a connection with server system 130 through network connection 150. 

15 Server system 130 can be a remote server system accessible via the Internet or it 
can be a server in a local area network. 

Server 130 includes a database 140 that includes either the device driver 
needed for operation of device 120, or one or more references to locations (i.e., 
20 other servers) where the device driver may be found. Once the appropriate device 
driver is located, at step 250, the device driver is forwarded via network connection 
150 to host 110. At step 260, host 110 receives the device driver, installs, and 
loads it into memory. As it is described in further detail below, the device driver is 
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then integrated into host 1 10's system software, so that host 110 can communicate 
with and control device 120. 

The above described system, including the application software 322 for 
5 detecting the attachment of peripheral device 120 and configuring host system 110 
is implemented in association with hardware system 310 (FIG. 3 A) and software 
system 320 (FIG. 3B) and is described in further detail below. The following 
hardware and software embodiments are provided by way of example. The 
invention may be practiced either individually or in combination with other 
10 suitable hardware or software architectures or environments not described in detail 
herein. It should be noted that certain hardware and software component may be 
interchangeably implemented in form of software or hardware, in one or more 
embodiments of the invention. 

15 System Hardware Environment 

An embodiment of the system can be implemented as computer software in 
the form of computer readable code executed on host 110 or server system 130. 
Host 110 and server system 130 can be implemented in form of a general purpose 
computing system 310, in accordance with one or more aspects of the invention. 

20 FIG. 3 A illustrates an example of the components of computing device 310. 
Computing device 310 includes a central processor unit (CPU) 301, a main 
memory 302, an input/output controller 303, optional cache memory 304, user 
interface devices 305 (e.g., keyboard, pointing device, etc.), storage media 306 
(e.g., hard drive, memory, etc.), a display screen 307, a communication interface 
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308 (e.g., a network card, a modem, or an integrated services digital network 
(ISDN) card, etc.), and a system synchronizer (e.g., a clock, not shown in FIG. 
3A). 

Processor 301 may or may not include cache memory 304 utilized for 
storing frequently accessed information. One or more input/output devices such as 
a printing or a scanning device may be attached to computing system 310. A 
communication mechanism, such as a bi-directional data bus 300, can be utilized to 
provide for means of communication between system components. Host 1 10 and 
server 130 may be capable of communicating with one another and other systems 
through communication interface 308. 

In one or more embodiments, host 1 10 or server 130 may not include all the 
above components, or may include additional components for additional 
functionality or utility. For example, host 1 10 can be a laptop computer or other 
portable computing device that can send messages and receive data through 
communication interface 308. The system hardware environment may also be 
embodied in an embedded system such as a set-top box, a personal data assistant 
(PDA), a wireless communication unit (e.g., cellular phone), or other similar 
hardware platforms that have information processing and/or data storage and 
communication capabilities. 

In embodiments of the system, communication interface 308 can send and 
receive electrical, electromagnetic, or optical signals that carry digital data streams 
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representing various types of information including program code. If 
communication is established via the Internet, server system 130 may transmit 
program code to host 1 10 through Internet connection 150. The program code can 
be executed by central processor unit 301 or is stored in storage media 306 or other 
non-volatile storage for later execution. 

Program code may be transmitted via a carrier wave or may be embodied in 
any other form of computer program product. A computer program product 
comprises a medium configured to store or transport computer readable code or a 
medium in which computer readable code may be embedded. Some examples of 
computer program products are CD-ROM disks, ROM cards, floppy disks, 
magnetic tapes, computer hard drives, and network server systems. 

In one or more embodiments of the invention, processor 301 is a 
microprocessor manufactured by Motorola, Intel, or Sun Microsystems 
Corporations. The named processors are for the purpose of example only. Any 
other suitable microprocessor, microcontroller, or microcomputer may be utilized. 

System Software Environment 

FIG. 3B illustrates computer software 320 suited for managing and 
directing the operation of the system hardware environment described above. 
Computer software 320 is, typically, stored in storage media 306 and is loaded into 
memory 302 prior to execution. Computer software 320 includes system software 
321 and application software 322. Depending on system implementation, certain 
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aspects of computer software 320 can be loaded on one or more computing 
systems. 

System software 321 includes control software such as an operating system 
5 that controls the low-level operations of computing system 310. Low-level 
operations include the management of the system's resources such as memory 
allocation, file swapping, and other core computing tasks. In one or more 
embodiments of the invention, the operating system is Microsoft Windows CE®, 
Microsoft Windows NT®, Macintosh OS®, or IBM OS/2®. However, any other 
10 suitable operating system may be utilized. 

Application software 322 can include one or more computer programs that 
are executed on top of system software 321 after being loaded from storage media 
306 into memory 302. In a client-server architecture, application software 322 
15 may include a client software 322(a) and a server software 322(b). Referring to 
FIG. 1 for example, in one embodiment of the invention, client software 322(a) is 
executed on host 1 10 and server software 322(b) is executed on server 130. 

Computer software 320 may also include a web browser software 323 for 
20 communicating with the Internet. Further, computer software 320 includes a user 
interface 324 (e.g., a Graphical User Interface (GUI)) for receiving user commands 
and data. The commands and data received are processed by the software 
applications that run on the computing system 310. The system architectures and 
environments described above are for purposes of example only. Embodiments of 
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the invention may be implemented in any type of system architecture or processing 
environment. 

Application Software for Detecting and Communicating With a 
Peripheral Device 

In accordance with one or more aspects of the invention, application 

software 322 runs partly on host system 1 10 and partly on server system 130 and is 

directed to a method of detecting the attachment a peripheral device 120 to a host 

1 10. Client application 322(a) is the part of application software 322 that runs on 

host 110 and depends on certain components of host 1 10 to detect the attachment 

of device 120. Figure 4 illustrates a block diagram of host 110 and device 120 

attached together via pipe 420. Pipe 420 is a logical association between host 110 

and device 120 implemented to promote communication between host 110 and 

device 120. 

According to one aspect of the invention, host 110 includes a high-speed 
bus. A bus typically refers to a common pathway or channel for transfer of data 
between multiple components of a system. The high-speed bus of the invention, in 
one or more embodiments, is implemented based on technologies such as 
Universal Serial Bus® (USB) or Firewire® (IEEE Standard 1394). USB is a 
hardware interface for connecting standard peripheral devices such as the 
keyboard, mouse, joystick, scanner, printer, and telephony devices to a computing 
system. USB can typically support the attachment of up to 127 devices. Firewire 
or the IEEE 1394 standard is a high-speed serial bus developed by Apple and 
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Texas Instruments that allows for the connection of up to 63 devices. In one or 
more embodiments of the system, host 110 uses the above bus technologies to 
detect the attachment of and identify device 120. 

As shown in FIG. 4, in accordance with one aspect of the invention, host 
110 includes a hub 410 to which device 120 attaches via pipe 420. Hubs are 
wiring concentrators that define an attachment point in a bus (e.g., USB) 
architecture. An attachment point is typically an addressing scheme that 
corresponds with a unique identifier which allows the host to communicate with 
the attached peripheral. Attachments points are also referred to as ports. In 
embodiments of the invention, device 120 can be attached to one or more ports on 
hub 140. When device 120 attaches to host 1 10, an embedded hub (i.e., root hub) 
at host 1 10 senses the presence of device 120 on a port and interrogates device 120 
for identifying information. 

Hubs are associated with status bits that are used to detect and report the 
attachment or removal of a device on a port. A change in configuration of status 
bits indicates the attachment or removal of a device. Figure 5 illustrates a flow 
diagram of a method by which host system 1 10 detects the attachment of device 
120. Referring to FIG. 5, host 110 at step 510 (and periodically) queries hub 410 
for status bits to detect the attachment of a device. 

At step 520, if the configuration of status bits do not indicate the attachment 
of a device then the system reverts back to step 510 and continues to wait until the 
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attachment of a device is detected. Otherwise, once the change in configuration of 
status bits indicate the attachment of a device, at step 530, host 110 enables the 
attachment port. A port is enabled when electrical power is supplied to the port as 
the result of writing registers in system hardware. At step 540, the system 
5 enumerates the port to which the device is attached by assigning a unique address 
to it. 

Host 1 10 can access device 120 by referencing the unique address assigned 
to it as the result of the enumeration activity. In embodiments of the system, host 

10 110 establishes a control pipe 420 with device 120 using the assigned unique 
address and endpoint number 0. An endpoint is a uniquely identifiable portion of 
device 120. Each endpoint is given at design time a unique identifier called 
endpoint number. Further, each endpoint has a device-determined direction of data 
flow. The combination of the device address, endpoint number, and data flow 

15 direction allows each endpoint to be uniquely referenced by host 110. 

As stated above, device 120 is accessible by a unique address. Device 120, 
in certain embodiments of the system, also supports one or more endpoints with 
which host 110 may communicate. Device 120 supports a specially designated 
20 endpoint 0 to which control pipe 420 attaches. Associated with endpoint 0 is the 
information required to completely describe device 120. Endpoint 0 provides a 
communication pipe by which host 110 can submit requests (e.g., standard USB 
commands) to device 120. Device 120 responds to host 110's requests by 
forwarding device identifying information. 
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In one embodiment of the invention, endpoint number 0 is accessible once 
device 120 is attached and enumerated. Control pipe 420, associated with endpoint 
number 0, is also called the default control pipe. According to USB standards a 
USB device is required to implement a default control method (i.e., a default 
control pipe) that uses both input and output endpoints with endpoint number 0. 
Typically, the USB system software uses this default control method to initialize 
and generically manipulate the logical device. In embodiments of the invention, 
system software 321 includes USB system software. 

The USB system software causes, a default control pipe 420 to be 
established between host 1 10 and device 120 once the device is powered. Control 
pipe 420 provides host 1 10 with access to device 120's configuration, status, and 
control information. Furthermore, control pipe 420 is used by the host 110's 
system software to configure and initialize device 120 after attachment. In 
accordance with one aspect of the invention, control pipe 420 can also be used by 
device specific software after device 120 is configured. Host 110's system 
software retains ownership of control pipe 420 and mediates its use by other 
software. Once host 110 has established a communication and control interface 
with device 120 through pipe 420, at step 550, an attachment notification is 
forwarded to client software 322(a) running on host 110. 

In one or more embodiments, host 110 interacts with device 120 via system 
software 321 and client software 322(a). System software 321 and client software 
322(a) are loaded and run on host 1 10. Referring to FIG. 3B, in embodiments of 
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the invention, system software 321 includes the operating system for operating host 
110 and other foundation software such as a host controller (not shown). When 
host 110 is turned on the operating system is loaded into host 110's. system 
memory. The host controller can be either loaded as part of the operating system 
5 or on top of the operating system, depending on system implementation. The host 
controller is part of system software 321 that is responsible for managing control 
and data flow between host 110 and device 120. As it is described in further detail 
below, the host controller also performs the task of collecting device status and 
activity statistics. 

10 

Once device 120 is detected and identified by host 1 10, in accordance with 
one aspects of the invention, special control software for controlling device 120 is 
loaded on host 110. FIG. 6 illustrates a method of locating and loading control 
software, particularly a device driver, on host 110 after client software 322(a) 

15 receives notification of attachment of device 120 to host 110. A device driver is 
control software written for a specific device that dictates the precise machine 
language necessary to communicate with and control that device. Therefore, for 
each device, a certain device driver needs to be installed on host 1 10. Thus, system 
software 321 provides the foundational communication means between host 110 

20 and device 120, while the device driver provides host 110 with specific details on 
how to communicate with and control device 120. 

In embodiments of the invention, at step 610, system software 321 collects 
device information by querying device 120 using the standard mechanisms built 
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into system software's communication protocol (e.g., the USB protocol). A device 
typically represents itself to a host system using a standardized set of data 
structures described in the system communication protocol specifications. In one 
or more embodiments of the invention, device 120 is a USB device and thus 
represents itself to host 1 10 based on standards set forth in the USB specifications. 
To collect device information, the host controller software requests from device 
120 to forward the device descriptor for device 120 to endpoint 0 at the default 
USB address. In response to the request, device 120 forwards its device descriptor 
to host 110. A device descriptor includes specific information about a device's 
specific communication requirements and control architecture. 

In one or more embodiments of the system, the device descriptor, for 
example, includes the following information about device 120: device class, device 
subclass, device protocol, vendor identification number (e.g., IdVendor), product 
identification number (e.g., IdProduct), manufacturer information (e.g., 
iManufacturer), product information (e.g., iProduct), product serial number 
(iSerialNumber), and binary coded decimal device identifier (BcdDevice). It 
should be noted that the above provided list is not inclusive. Further information 
or items may be included or excluded from the above list depending on system 
implementation or type of device attached to host 110. 

For example, in certain embodiments of the invention, in addition to the 
above information, the device descriptor may also include information about an 
operating software platform (e.g., Microsoft Windows 2000®, UNIX®, Mac OS®, 
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etc.) or computing hardware platform (Pentium®, SPARC®, PowerPC®, etc.) that 
are compatible with the requirements of device 120. Access to the above device 
specific information enables host 110 to determine whether its operating 
environment is compatible with device 120's system requirements. Further, based 
5 on the above information host 110 can determine how to communicate with and 
control device 120. 

Host 110 collects sufficient information about device 120 based on the 
device descriptor to identify the type and requirements of device 120. Thereafter, 
10 host 1 10 attempts to locate a control software or driver for device 120 based on the 
collected information. If the driver is locally accessible, then system software 321 
loads the driver on host 110. A driver is considered locally available if it is stored 
on host 1 10 or device 120. 

15 If system software 321 fails to locate the appropriate driver for device 120, 

or in order to install and load a new version of an outdated locally accessible 
driver, system software 321 transfers control to client software 322(a) by loading a 
proxy class driver. A proxy driver is a portion of client software 322(a), or a 
portion of system software 321 running on host system 110, that depending on 

20 system implementation, acts as a temporary substitute driver when no driver is 
found for a device attached to the system, or when a present driver is out dated. 
Once the proxy class driver is loaded, it acts as a client that communicates with 
server 130 to locate the appropriate device driver. 
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Client software 322(a) accesses device information collected by system 
software 321, at step 610. At step 620, using the device information, client 
software 322(a) forwards a request packet across network connection 150 (e.g., a 
standard TCP/IP network connection) to remote sever system 130. Server system 
5 130 can be connected to host 1 10 in a local area network (LAN). Alternatively, it 
may be accessible over a wide area network (WAN), such as the Internet. The 
submitted request packet includes sufficient information for server 130 to find a 
device driver that is compatible with host 1 1 0 and device 1 20. 

10 The design of a device driver is not only dependent on the specifications of 

the peripheral device it is implemented to drive, but also on the host's hardware 
and software platform to which the device attaches. Particularly, in embodiments 
of the invention applicable to embedded hosts, system software 321 is proprietary 
software developed by the manufacturer of the host device. As such, in 

15 embodiments of the invention, the submitted request to server 130, in addition to 
device specific information (e.g., information obtained from the device descriptor), 
also includes host specific information (e.g., information defining hardware 
configuration and operating system specifications of host 110). Client software 
322(a), at step 620, forwards all device and host specific information to server 
20 software 322 (b) running on server 130. 

Server software 322(b) is implemented to run on server system 130 to 
service submitted requests by client software 322(a). Server 130, in accordance 
with one aspect of the invention, includes database 140 used for storing one or 
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more control software applications (e.g., device drivers) for controlling one or 
more peripheral devices. Information included in database 140 can be either 
locally stored in one or more storage devices in server 130 or can be implemented 
across one or more platforms linked to server 130 (e.g., in a distributed network 
5 environment). 

Server software 322(b) running on server 130 receives a request submitted 
by client software 322(a) for finding a device driver for device 120 that can be 
integrated with host 110's system software 321. At step 630, server software 

10 322(b) after analyzing the request based on device and host specific information 
included therein, searches database 140 for available drivers that can satisfy the 
limitations and requirements of host 1 10 and device 120. In embodiments of the 
invention, an appropriate driver in addition to matching the device class, 
manufacturer, product id, serial number, or vendor id for device 120, also verifies 

15 that the device driver can appropriately interface with the operating system and 
hardware platform of host 1 10. 

If a compatible driver is found, server software 322(b) includes the driver's 
executable code in a communication packet and forwards it to host 110, at step 
20 640. Client software 322(a) receives the packet forwarded by server 130 
depacketizes driver's executable code and installs it on host 110. In embodiments 
of the invention, the format of the driver code is in object form such that client 
software 322(a) can load the driver into a storage medium (e.g., system memory) in 
host 110. Client software 322(a) then incorporates the driver code into system 
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software 321 to enable host 110 to support device 120. The device driver, once 
installed and loaded, provides system software 321 with instruction on how to 
communicate with device 120. 

5 According to one or more aspects of the system, client software 322(a) 

includes a proxy class driver that allocates the appropriate memory and other 
system resources needed to load the executable object code received from server 
130 into system software 321. The executable object code is installed and loaded 
on host 1 10 by the proxy class driver. The proxy class driver is responsible for 
10 loading the driver into memory. The proxy class driver sets up the needed 

memory, stacks code segments, and calls the device driver's entry point. An entry 
point is a reference to a callable function. The device driver then registers the 
device driver with system software 321 (e.g., the operating system) and takes over 
control of communications with the device. 

15 

In embodiments of the invention, host 110 stores the object code for the 
device driver received from server system 130 in a long term storage medium (e.g., 
hard drive). Storing the driver allows system software 321 to instantly load the 
driver when it detects the attachment of the device associated with that driver 
20 instead of submitting a request to server 130. In embodiments of the invention that 
do not include long term storage media, a reference to the remote storage location 
(e.g., the Internet site where the device driver was found) of the driver is preserved, 
in a cache for example. Cache, pronounced "cash," is a readily accessible data 
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storage area that holds frequently or recently referenced information and is 
typically used to speed up data transfer or retrieval. 

As such, client software 322(a) forwards a request to server software 322(b) 
5 with the exact location where the driver for a particular device can be found, 
thereby forgoing the need for a search to find the driver all over again. In certain 
embodiments of the invention, client software 322(a) periodically submits a 
request to server software 322(b) to search database 140 for any updated versions 
of the control software or device driver for device 120, for example, to insure that 
10 the latest version is available on host 1 10. 

Examplary Embodiment Based on USB Architecture 

The following includes the description of an examplary embodiment of the 
invention as applicable to the USB architecture, in order to provide a better 
15 understanding of the invention. It is noteworthy that the following description is 
provided by way of example, however, and should not be construed to limit the 
invention to the USB architecture only. 

In one or more embodiments of the invention, a USB device is connected to 
20 a host system via a USB port on the system bus. Once the device is detected by the 
host system through the enumeration process, the host system searches for a driver 
for the USB device. The USB device enumerator communicates with various class 
drivers including the operating system (O.S.) specific class drivers. The device 
enumerator maintains information about the USB tree typology and various 
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information and handles related to each device currently on the bus. The 
enumerator uses the USB device driver (USB Bus Class Driver) to send and 
receive information to each of the various devices. 

5 The Bus Class Driver is specific to a particular bus interface, such as, USB, 

1394, for example, so that the Application Program Interface (API) to a specific 
bus interface is standard for all devices and applications that utilize the bus. In 
addition, this interface provides more flexibility in moving from one bus 
architecture to another. Each type of USB device has a class associated with it. 

10 For example, the Human Interface Device (HID) class driver is used for keyboards 
and mice, where as the Printer class driver, supports USB printers. Currently there 
are seven classes defined by the USB organization, these are the Human Interface 
Device Class, Printer Device Class, Power Device Class, Monitor Device Class, 
Audio Device Class, Communications Device Class, and Common Class. Built 

1 5 into the USB architecture is a class driver which can be operating system specific, 
that is, a standard API for communicating with devices on the USB Bus that do not 
have a specific class type. 

The USB device driver (USB Bus Class Driver) is a defined API used for 
20 communicating on the USB bus and is hardware independent. This driver layer 
controls all of the USB specific functions and various communications on the bus. 
In accordance to one or more aspects of the invention, a class driver is developed 
so that the API to a specific class of devices is standard for all devices of that 
particular class. The above-described layered architecture allows the 
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implementation of a proxy class that can communicate with existing software 
architectures on a host system to find the appropriate device driver for a detected 
device. 

5 The concept of the proxy class can be extended to monolithic driver 

architectures, as well. In a monolithic architecture, system software is designed to 
control and communicate with a particular device or hardware portion, while in a 
layered architecture the top layers are implemented independent from the specific 
hardware design and thus can provide general support for a set of hardware 
10 interfaces. Win32 Driver Model (WDM) is an example of layered device driver 
architecture that consolidates drivers for Windows 95/98 and Windows NT. It 
allows a hardware vendor to write one Windows driver for its peripheral device 
that works with both Win 95/98 and NT. 

15 In certain embodiments of the system, the proxy acts as a driver on behalf 

of the device if the device does not have support within the host system software at 
the time the device is first detected. The proxy driver is not capable of controlling 
or communicating with the device, outside of the standard USB commands. The 
proxy class, however, is capable of searching for a driver capable of supporting the 

20 newly inserted device. The proxy class searches either a local database or a remote 
database server in communication with the host system. The proxy class gets 
information from the device via the standard USB requests for descriptor 
information. Using this information along with other information gathered from 
the operating system (i.e. operating system, hardware, cpu), the proxy class 
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submits a request to the database for a driver suitable for the device, operating 
system, and hardware platform. In response, the server forwards a loadable driver 
module (e.g., object code) capable of driving the device, or an error message, if the 
server is unable to find an appropriate driver. 

5 

In accordance with an aspect of the invention, if a suitable driver is found, 
the proxy driver will load the newly downloaded object code into host system's 
memory. The object code will have specific entry points (callable functions) that 
must be implemented by the loaded driver. In some embodiments, a header is 

10 present with the object code, such that, the proxy class can determine where the 
various entries points are contained within the binary file and how the proxy class 
can locate the loadable code such that it can be run within the operating system. 
The loadable object code forwarded by the server includes the appropriate 
functionality and interfaces so that it can integrate with the host's operating system 

15 and take over control and communication with the device attached to the host 
system. 

In embodiments of the invention, to integrate the object code with the 
host's operating system, the proxy class is loaded on a particular platform and tied 
20 into the given software architecture. The following code segment, is an examplary 
method by which the object code registers itself with the layered device driver 
architecture of the invention that is implemented to provide an interface between 
class drivers and the operating system. 
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void PROXY_StartDriver() 
{ 

st_REGISTER_PROXY USBRegister; 



/* 



Need to register the PROXY class to the stack. 

The Proxy class does not specify device class\subclass\protocol 

It owns all device that are not owned by a parent class 

USBRegister.RDEntryPointStart=(FUNCPTR)PROXY_Start; 

USBRegister.RDEntryPointStop=(FUNCPTR)PROXY_Stop; 

CLASS_RegisterProxy(&USBRegister); 

return; 

} 



UINT CLASS_RegisterProxy(st_REGISTER_PROXY 'Driver) 
{ 

ProxyStart=Driver->RDEntryPointStart; 

ProxyStop=Driver->RDEntr>PointStop; 

return(SUCCESS); 

} 



The PROXY_StartDriver is called during the system startup. The 

execution of this code registers a set of function calls with the USB driver stack. 

These entry points are called whenever no other class driver is found to support an 

attached device upon insertion. Once a device is inserted and after the proxy class 

and its entry point are registered with the underlying software layer, the underlying 

layers provide a communication channel to provide basic communication with the 

device. Thereafter, either the underlying layer or the proxy class itself can request 

information from the device using the standard USB protocol commands. These 

commands are explained in section 9 A of the USB 1.1 Specification. Examples of 

some of these commands are provided below. 

GET_STATUS - This request returns status for the specified recipient. 

CLEAR_FEATURE - This request is used to clear or disable a specific feature. 
SET_FEATURE - This request is used to set or enable a specific feature. 

SET_ADDRESS - This request sets the device address for all future device 

accesses. 

GET_DESCRIPTOR - This request returns the specified descriptor if the descriptor 

exists. 

SET_DESCRIPTOR - This request may be used to update or adding descriptors. 
GET_CONFIGURATION- This request returns the current device configuration value. 
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SETCONFIGURATION - This request sets the device configuration. 
G ET_INTERF ACE - This request returns the selected alternate setting for the 

specified interface. 

SET_INTERFACE - This request allows the host to select an alternate setting for 

specified interface. 

SYNCH_FRAME - This request is used to set and then report an endpoint' s 

synchronization frame. 

In The GET_DESCRIPTOR command, for example, is used to retrieve the 
various descriptors that are present in the USB device. USB commands are sent 
via a default pipe also known as endpointO and act as a control endpoint. Every 
USB device compliant with the USB specification is required to implement a 
plurality of descriptors. In one or more embodiments of the invention the USB 
device is represented by a plurality of descriptors, including device descriptor, 
configuration descriptor, interface descriptor, endpoint descriptor, and string 
descriptor. Tables one through five include the description of various fields 
included in each of the above-named descriptors and the details associated with 
those fields, in accordance with Universal Serial Bus Specification Revision 1.1, 
Chapter 9.5. 



TABLE 1: DEVICE DESCRIPTOR 



'Offset;. 

• ' 's ~" ' *. «v* 


Field V: • .,' . ;} v 


if; 
z * 
e 


^aluej,;-;^^. 


Description • A&i? ^i^^^^K-A^r; ; 
' ''Jit"' 1 - k<^f:*-:-ci r ' ';-V'- M-ri?- \-\:\ ■ ■ v.;.-- y • ' 


0 


B length 


1 


Number 


Size of this descriptor in bytes 


1 


BdescriptorType 


1 


Constant 


DEVICE Descriptor Type 


2 


BcdUSB 


2 


BCD 


USB Specification Release Number in 
Binary-Coded Decimal (i.e., 2.10 is 
0x210). This field identifies the 
release of the USB Specification that 
the device and its descriptors are 
compliant with. 


4 


BdeviceClass 


1 


Class 


Class code (assigned by USB). 
If this field is reset to 0, each interface 
within a configuration specifies its 
own class information and the various 
interfaces operate independently. 
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If this field is set to a value between 1 
and OxFE, the device supports 
different class specifications on 
different interfaces and the interfaces 

mjiv not rmpmtt* inHpn^nH^ntTi/ Thic 
may nut ujJClalC UIUCfJGIlUCIILljr . 1 111b 

value identifies the class definition 
used for the aggregate interfaces. (For 
example, a CD-ROM device with 
audio and digital data interfaces that 
require transport control to eject CDs 
or start them spinning.) If this field is 
set to OxFF, the device class is vendor 
snecific 


5 


BDeviceSubClass 


1 


SubClass 


Subclass code (assigned by USB). 
These codes are qualified by the value 
of the bDeviceClass field. If the 
bDeviceCIass field is reset to 0, this 
field must also be reset to 0. If the 
bDeviceClass field is not set to OxFF, 
all values are reserved for assignment 
by USB. 


6 


BdeviceProtocol 


I 


Protocol 


Protocol code (assigned by USB). 
These codes are qualified by the value 
of the bDeviceClass and the 
bDeviceSubClass fields. If a device 
supports class-specific protocols on a 
device basis as opposed to an interface 
basis, this code identifies the protocols 

trlflf t nf r\ f^y/ \ c r* ncpc ac <H f» ft n f*r\ Ywt th<* 
Llitll 111C UCVILt Ubcb ab UC1111CU uy LI1C 

specification of the device class. If 
this field is reset to 0, the device does 

not use pla<;<; <snpfiflf* nrr»f orr»1 <; nn a 
device basis However it mav use 
class specific protocols on an interface 
basis. If this field is set to OxFF, the 
device uses a vendor specific protocol 
on a device basis. 


7 


BmaxPacketSizeO 


1 


Number 


Maximum packet size for endpoint 
zero 

(only 8, 16, 32, or 64 are valid) 


8 


IdVendor 


2 


ID 


Vendor ID (assigned by USB) 


10 


IdProduct 


2 


ID 


Product ID (assigned by the 
Manufacturer) 


12 


BcdDevice 


2 


BCD 


Device release number in binary- 
coded decimal 


14 


Imanufacturer 


1 


Index 


Index of string descriptor describing 
manufacturer 


15 


Iproduct 


1 


Index 


Index of string descriptor describing 
product 


16 


IserialNumber 


1 


Index 


Index of string descriptor describing 
the device's serial number 


17 


BNumConfigurations 


1 


Number 


Number of possible configurations 
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A device descriptor describes general information about a USB device. It 
includes information that applies globally to the device and all of the device's 
configurations. As explained earlier, USB devices have an endpoint zero used by 
5 the default pipe. In certain embodiments of the system, the maximum packet size 
of a device's endpoint zero is described in the device descriptor. Endpoints 
specific to a configuration and its interface(s) are described in the configuration 
descriptor. A configuration and its interface(s) do not include an endpoint 
descriptor for endpoint zero. 

10 

The descriptor describes the number of interfaces provided by the 
configuration. Each interface may operate independently. For example, an ISDN 
device might be configured with two interfaces, each providing 64 kBs bi- 
directional channels that have separate data sources or sinks on the host. Another 
1 5 configuration might present the ISDN device as a single interface, bonding the two 
channels into one 128 kBs bi-directional channel, for example. When the host 
requests the configuration descriptor, all related interface and endpoint descriptors 
are returned. 

20 TABLE 2 : CONFIGURATION DESCRIPTOR 



Offset : 


- : Field * - > 


Size- 


-Value 


v'*r feiS*-* Description x\ :-V: : :\ - * J 


0 


Blength 


1 


Number 


Size of this descriptor in bytes 


1 


BDescriptorType 


1 


Constant 


CONFIGURATION 


2 


WTotalLength 


2 


Number 


Total length of data returned for 
this configuration. Includes the 
combined length of all 
descriptors (configuration, 
interface, endpoint, and class or 
vendor specific) returned for this 
configuration. 
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4 


BNumlnterfaces 


1 


Number 


Number of interfaces supported 
by this configuration 


5 


BConfiguration Value 


1 


Number 


Value to use as an argument to 
Set Configuration to select this 
configuration 


6 


IConfiguration 


1 


Index 


Index of string descriptor . 
describing this configuration 


7 


BMAttributes 


1 


Bitmap 


Configuration characteristics 
D7 Bus Powered 
D6 Self Powered 
D5 Remote Wake up 
D4..0 Reserved (reset to 0) 
A device configuration that uses 
. power from the bus and a local 
source sets both D7 and D6. The 
actual power source at runtime 
may be determined using the Get 
Status device request. 
If a device configuration 
supports remote wakeup, D5 is 
set to I . 


8 


MaxPower 


1 


mA 


Maximum power consumption 
of USB device from the bus in 
this specific configuration when 
the device is fully operational. 
Expressed in 2 mA units (i.e., 50 
= 100 mA). 

Note: A device configuration 
reports whether the 
configuration is bus-powered or 
self-powered. 

Device status reports whether 
the device is currently self- 
powered. If a device is 
disconnected from its external 
power source, it updates device 
status to indicate that it is no 
longer self-powered. 
A device may not increase its 
power draw from the bus, when 
it loses its external power 
source, beyond the amount 
reported by its configuration. 
If a device can continue to 
operate when disconnected from 
its external nower source it 
continues to do so. If the device 
cannot continue to operate, it 
fails operations it can no longer 
support. Host software may 
determine the cause of the 
failure by checking the status 
and noting the loss of the 
device's power source. 
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A USB device has one or more configuration descriptors. Each 
configuration has one of more interfaces and each interface has one or more 
endpoints. An endpoint is not shared among interfaces within a single 
configuration unless the endpoint is used by alternate settings of the same 
interface. Endpoints may be shared among interfaces that are part of different 
configurations without this restriction. Once configured, devices may support 
limited adjustments to the configuration. If a particular interface has alternate 
settings, an alternate may be selected after configuration. 



A configuration provides one or more interfaces, each with its own 
endpoint descriptors describing a unique set of endpoints within the configuration. 
When a configuration supports more than one interface, the endpoints for a 
particular interface immediately follow the interface descriptor in the data returned 
by the Get Configuration request. 



TABLE 3: INTERFACE DESCRIPTOR 



OfT; 

'set 


;v J- Field v , 


Size^ 




^Cv^fe*- ''^Descriptors • - ' ' 


0 


B length 


1 


Number 


Size of this descriptor in bytes 


1 


BDescriptorType 


1 


Constant 


INTERFACE Descriptor Type 


2 


BInterfaceNumber 


1 


Number 


Number of interface. Zero-based 
value identifying the index in the 
array of concurrent interfaces 
supported by this configuration. 


3 


BAltenateSetting 


1 


Number 


Value used to select alternate setting 
for the interface identified in the 
prior field 


4 


BNumEndpoints 


1 


Number 


Number of endpoints used by this 
interface (excluding endpoint zero). 
If this value is 0, this interface only 
uses endpoint zero. 


5 


BinterfaceClass 


1 


Class 


Class code (assigned by USB) 

If this field is reset to 0, the interface 

does not belong to any USB specified 
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device class. 

If this field is set to OxFF, the 
interface class is vendor specific. 
All other values are reserved for 
assignment by USB. 


6 


BInterfaceSubClass 


1 


Subclass 


Subclass code (assigned by USB). 
These codes are qualified by the 
value of the blnterfaceClass field. If 
the blnterfaceClass field is reset to 0, 
this field must also be reset to 0. If 
the blnterfaceClass field is not set to 
OxFF, all values are reserved for 
assignment by USB. 


7 


B InterfaceProtocol 


1 


Protocol 


Protocol code (assigned by USB). 
These codes are qualified by the 
value of the blnterfaceClass and the 
blnterfaceSubClass fields. If an 
interface supports class-specific 
requests, this code identifies the 
Drotocols that the device uses as 
defined by the specification of the 
device class. 

If this field is reset to 0, the device 
does not use a class specific protocol 
on this interface. 

If this field is set to OxFF, the device 
uses a vendor specific protocol for 
this interface. 


8 


Interface 


1 


Index 


Index of string descriptor describing 
this interface 



An interface descriptor is returned as part of a configuration descriptor. An 
interface may include alternate settings that allow the endpoints and/or their 
characteristics to be varied after the device has been configured. The default 
setting for an interface is alternate setting zero. The Set Interface request is used to 
select an alternate setting or to return to the default setting. The Get Interface 
request returns the selected alternate setting. Alternate settings allow a portion of 
the device configuration to be varied while other interfaces remain in operation. If 
a configuration has alternate settings for one or more of its interfaces, a separate 
interface descriptor and its associated endpoints are included for each setting. 
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If a device configuration supported a single interface with two alternate 
settings, the configuration descriptor is followed by an interface descriptor with the 
blnterfaceNumber and bAlternateSetting fields set to zero and then the endpoint 
descriptors for that setting, followed by another interface descriptor and its 
5 associated endpoint descriptors. The second interface descriptor's 

blnterfaceNumber field would also be set to zero, but the bAlternateSetting field of 
the second interface descriptor would be set to one. 



In accordance with one or more embodiments if the invention, if an 
10 interface uses endpoint zero, no endpoint descriptors follow the interface descriptor 
and the interface identifies a request interface that uses the default pipe attached to 
endpoint zero. In this case, the bNumEndpoints field shall be set to zero. An 
interface descriptor may not include endpoint zero in the number of endpoints. 



1 5 TABLE 4: ENDPOINT DESCRIPTOR 



Offset* 


^.'^Field ^W^r 


Size". 


^Values r 


^Description : ^ ■'" • .V- 


0 


Blength 


1 


Number 


Size of this descriptor in bytes 


1 


B DescriptorType 


1 


Constant 


ENDPOINT Descriptor Type 


2 


BEndpointAddress 


1 


Endpoint 


The address of the endpoint on the 
USB device described by this 
descriptor. The address is encoded as 
follows: 

Bit 0..3: The endpoint number 
Bit 4. .6: Reserved, reset to 0 
Bit 7: Direction, ignored for control 
endpoints 

0 OUT endpoint 

1 IN endpoint 


3 


BmAttributes 


1 


Bitmap 


This field describes the endpoint's 
attributes when it is configured using 
the bConfiguration Value. 
Bit 0 1 : Transfer Type 

00 Control 

01 Isochronous 
10 Bulk 
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1 1 Interrupt 


4 


WMaxPacketSize 


2 


Number 


Maximum packet size this endpoint 
is capable of sending or receiving 
when this configuration is selected. 
For isochronous endpoints, this value 
is used to reserve the bus time in the 
schedule, required for the per frame 
data 

payloads. The pipe may, on an 
ongoing basis, actually use less 
bandwidth than that reserved The 
device reports, if necessary, the 
actual bandwidth used via its normal, 
non-USB defined mechanisms. 
For interrupt, bulk, and control 
endpoints smaller data payloads may 
be sent, but will terminate the 
transfer and may or may not require 
intervention to restart. 


6 


Binterval 


1 


Number 


Interval for polling endpoint for data 
transfers. Expressed in milliseconds. 
This field is ignored for bulk and 
control endpoints. For isochronous 
endpoints this field must be set to 1. 
For interrupt endpoints, this field 
may range from 1 to 255. 



In embodiments of the invention, each endpoint used for an interface has its 
own descriptor. This descriptor contains the information required by the host to 
determine the bandwidth requirements of each endpoint. An endpoint descriptor is 
5 returned as part of a configuration descriptor. 



TABLE 5: STRING DESCRIPTOR 



Offset 


Field 


Size 


Value 


Description 


0 


Blength 


1 


Number 


Size of this descriptor in bytes 


1 


BDescriptorType 


1 


Constant 


STRING Descriptor Type 


2 


Bstring 


n 


Number 


UNICODE encoded string 



In certain embodiments, string descriptors are optional. If a device does not 
10 support string descriptors, references to string descriptors within device, 

configuration, and interface descriptors are reset to zero. String descriptors use 
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UNICODE encoding as defined by The Unicode Standard, Worldwide Character 
Encoding, Version 1.0, Volumes 1 and 2, The Unicode Consortium, Addison- 
Wesley Publishing Company, Reading, Massachusetts. The UNICODE string 
descriptor is not NULL terminated. The string length is computed by subtracting 
5 two from the value of the first byte of the descriptor. 

Typically, the system software tries to match a driver loaded on the system 

with the newly found hardware or attached device. If, however, the system 

software is unable to locate a driver, the proxy class' entry function which was 

10 registered early will be called. An example of the code defining an entry point to 

the proxy class is listed below: 

UINT PROXY_BuildResolverInfo(stJ>ROXYJlEQUEST_DRlVER * Proxy Request, 
UINT Address, UINT Configuration, UINT Interface) 

{ 

1 5 st_URB JNTERFACEJNFO InterfaceUrb; 

st_URB_DEVICE_INFO DeviceUrb; 
st_URBJ3ET_STRING StringUrb; 
UINT Result; 
UCHAR *Buffer; 



20 /* 
*/ 



Get the ProductID and VendorlD for the unknown device 



DeviceUrb.Header.Function=USB_GET_DEVICE_DESCRIPTOR; 
DeviceUrb. Header.DeviceAddress=Address; 
25 Result=USB_GetDeviceDescriptor(&DeviceUrb); 
if(ResuIt) 

return(ERROR); 

/* Save the Vendor Info */ 

30 ProxyRequest->PC_IdVendor=DeviceUrb.DeviceDescriptor.idVendor; 

ProxyRequest->PC__IdProduct=DeviceUrb.DeviceDescriptor.idProduct; 
ProxyRequest->PC_IManufacrurer=DeviceUrb.DeviceDescriptor.iManufacturer; 
ProxyRequest->PC_IProduct=DeviceUrb.DeviceDescriptor.iProduct; 
ProxyRequest->PC_ISeriaINumber=DeviceUrb.DeviceDescriptor.iSerialNumber; 



35 /* 
*/ 

40 



Get the subclass and the protocol for the unknown device 

if(Configuration !=- 1 &&Interface !=- 1 ) 
{ 

InterfaceUrb.Header.Function=USB_GET_INTERFACE_DESCRlPTOR; 
InterfaceUrb.Header.DeviceAddress=Address; 
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InterfaceUrb.SeIectedConfiguration=Configuration; 
InterfaceUrb.SeIectedInterface==Interface; 
Resu!t=USB_GetInterfaceDescriptor(&InterfaceUrb); 
if(Result) 

return(ERROR); 

/♦ 

Save the class, subclass and protocol 

♦/ 

ProxyRequest- 

>PC_Class=InterfaceUrbJnterfaceDescriptor.bInterfaceClass; 
ProxyRequest->PC_SubClass 

=InterfaceUrb.lnterfaceDescriptor.bInterfaceSubClass; 
ProxyRequest- 

>PC_Protocol=InterfaceUrb.InterfaceDescriptor.bInterfaceProtocol; 
} 

/♦ 

Get the Device string 

To be DMA Safe, obtain a buffer from DMA Pool 

V 

Buffer=OS^AIIocDMAMem(USB_PROXY_STRING_SI2E); 
if(!Buffer) 

return(ERROR); 

/• 

Prepare the GETSTRING Urb 

V 

StringUrb.Header.Function=USBj3ET_STRING; 
StringUrb. Header. DeviceAddress=Address; 
StringUrb.StringIndex=DeviceUrb.DeviceDescriptor.iProduct; 
StringUrb.MaxLength=USB_PROXY_STRING_SIZE; 
StringUrb.StringBuffer=Buffer; 

StringUrb.StringDecodingFlag=USB_STRING_DECODE_ASCII; 

Result=USB_GetString(&StringUrb); 

if( Result) 

{ 

OS^FreeDMAMem(Buffer); 

retum(ResuIt); 

} 

/• 

Copy the DMA buffer into the caller's buffer 

V 

OS_Memmove(ProxyRequest>PC_DeviceString,Buffer+2,USB_PROXY STRI 
NG_SIZE); 

OS__FreeDMAMem(BufTer); 

return(SUCCESS); /*JOE 3-20*/ 

} 



In accordance with one aspect of the invention, the PROXYStart function 
in turn calls PROXY_BuildResolverInfo which, using the standard USB 
GET_DESCRIPTOR commands, builds enough information about the device so 
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that a server can determine the best fit for the device. An example of code defining 
the function listing for PROXY_BuildResolverInfo is listed below: 

void PROXY_Start(UINT DeviceAddress, UINT DeviceCon figuration, UINT 
Devicelnterface) 
{ 

UINT Result; 
st_PROXY_REQUEST_DRIVER ProxyRequest; 



V 



Fill the USB proxy data structure to pass to the resolver 

Result=PROXY_BuildResolverInfo(&ProxyRequest, 

DcviceAddress.DeviceConfiguration.Devicelnterface); 

if(Resuit) 

return; 

Pass the info to the resolver. The resolver will be implementation 
specific. It's job is to get the driver from somewhere (a remote server) 
change the ownership of the device to the new parent and load it 
the driver on the target. It returns a status 

Rcsult=PROXY_ResolveClass(&ProxyRequest); 
return; 

} 



After PROXY_Start calls PROXY_BuildResolverInfo, the proxy request is 
ready to be sent to the server. PROXY_ResolveClass is called which makes a 
request to the server. An examplary, pseudo code for the PROXY_ResolveClass is 
listed below: 

UNIT PROXY_ResolveC!ass(st_PROXY_REQUEST_DRIVER *Proxy Request) 
Establish connection with server 
Logon to server 

Pass the proxy Request to server 

Receive response to proxy request 
If(unable to find driver) 
Return ERROR. 



/* 



Driver Found 

Read Object Code header 

Determine Object Code Entry functions 
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Dynamically Link Object code 
Call Driver Entry Point 
Reset Device 
Return SUCCESS 



In one or more embodiments of the system, the proxy class uses standard 
networking protocols to make a connection to the server. Most network software 
provide the standard Berkeley Standard Distribution (BSD) TCP/UDP-IP for basic 
connection via a client/server model, for example. These functions are listed 



below: 



Accept - Accepts a connection on the specified socket (TCP only). 

bind - Binds a name to an unnamed socket. 

closesockct - Closes a socket and severs all connections. 

connect - Initiates a connection on a socket. 

fcntlsockct - Gets or sets a descriptor's status flag. 

gctpecrnamc - Gets the name of the peer to which a socket is connected. 

gctsockname - Retrieves the name of a socket. 

gctsockopt - Retrieves the value of a socket option. 

ip Configurelnterfacc - Configures the IP interface. 

ip_Gct - Retrieves IP information. 

listen - Listens for incoming connections on a socket (TCP only), 

rccv - Receives data on a socket. 

reevfrom - Receives data on a socket and retrieves the address of the sending host, 

select - Determines whether any descriptors are ready for reading or writing, or 

have an error pending, 

send - Sends data from a socket, 

sendto - Sends data from a socket. 

Setsockopt - Sets the value of a socket option. 

shutdown - Closes, or partially closes, a full-duplex connection by disabling 

receive and/or send operations on the specified socket, 

socket - Creates a new socket. 



After the connection is established, the data collected by the proxy driver is 
sent as a request to the server. The server receives the request and searches the 
database for a suitable driver using the following criteria: 

1) VendorlD and ProductID 

2) if CIass=FFH VendorlD+SubClass+Protocol 

3) InterfaceClass+InterfaceSubCIass+Protocol 
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5) InterfaceClass 

After the device class has been determined, the server looks for a 
combination of operating system and hardware platform. If the proper device class 
is determined, however, a driver is not found for a particular operating system, and 
an error is returned. If the proper device class is determined and the proper 
operating system is found, but the proper hardware platform is not found, then the 
server will return an error. If the proper device class is not determined, the server 
will return an error, as well. 

If the proper driver is found, the server generates a response with 
information about the driver along with the driver. The information could be a 
URL to a particular web address, advertisement information, a application 
executable, or any other associated information. In some embodiments, the proxy 
class first performs a check sum on the data received from the server to insure that 
all the information that has been sent by the server has been received by the client 
application (proxy class). If the data is determined to be valid, the proxy class will 
then proceed to read the object code header of the driver. As an example, the 
object code can be compiled to the Executable and Linking Format (ELF) object 
format developed and published by UNIX System Laboratories (USL) as part of 
the Application Binary Interface (ABI). The ELF standard is intended to 
streamline software development by providing developers with a set of binary 
interface definitions that extend across multiple operating environments. 
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Object files participate in program linking (building a program) and 
program execution (running a program). For convenience and efficiency, the 
object file format provides parallel views of a file's contents, reflecting the 
differing needs of these activities. An ELF header resides at the beginning and 
holds a "road map" describing the file's organization. Sections hold the bulk of 
object file information for the linking view: instructions, data, symbol table, 
relocation information, and so on. Object files therefore represent some control 
data with a machine-independent format, making it possible to identify object files 
and interpret their contents in a common way. Remaining data in an object file use 
the encoding of the target processor, regardless of the machine on which the file 
was created. 

In embodiments of the invention, using the standard tables built into the 
object files, the proxy class can determine the entry points within the file that are 
callable functions by itself and the operating system. This process is call 
relocation. Relocation is the process of connecting symbolic references with 
symbolic definitions. For example, when a program calls a function, the associated 
call instruction must transfer control to the proper destination address at execution. 
In other words, relocatable files must have information that describes how to 
modify their section contents, thus allowing executable and shared object files to 
hold the right information for a process's program image. 

In embodiments of the system, after the proxy class relocates the object 
code into system memory, the loaded driver is ready to be executed. The proxy 
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class calls the loaded driver's entry point, which is responsible for initializing the 
newly loaded driver, and performs the necessary resource allocation or 
initialization needed by the driver. 



For the driver to assume control of the newly inserted device, the proxy 
class issues a reset on the device such that the lower layers of software re- 
enumerate the device. Once the loaded driver's entry point is called and the driver 
registers itself with the lower level software, resetting of the device causes the 
lower level software to find the newly loaded driver, and to pass control and 
communication of the device to it. The listing below is an example of a code 
within a driver to attach itself to lower level software, according to one or more 
embodiments of the invention. 

void AUDIO_StartDriver() 
{ 

st_REGISTER_DRIVER USBRegister; 

/* 

Need to register the AUDIO STREAMING class to the stack. 

*/ 

USBRegister.RDCIass=USB_CLASS_AUDIO; 

USBRegister.RDSubCIass=USB_SUBCLASS_AUDIO_STREAMING; 

USBRegister.RDProtocol=USB_PROTOCOL_AUDIO; 

USB Reg ister. RDO wnerMask=DM AS K JC_I S JP; 

USBRegister.RDEntryPointDone=(FUNCPTR)AUDIO_TransferDone; 

USBRegister.RDEntryPointStart=(FUNCPTR)AUDIO_Start; 

USBRegister.RDEntryPointStop=(FUNCPTR)AUDIO_Stop; 

AudioCIassDriver=CLASS_RegisterDriver(&USBRegister); 



Applicati on Software for Directed Information Delivery 

One or more embodiments of the invention are directed to an on-line 
system that provides directed information delivery to targeted audience who use a 
particular peripheral device in conjunction with a host system connected to the on- 
line system. In accordance with one aspect of the invention, application software 
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322 causes advertisements or other relevant information about a peripheral device 
or a host system to be displayed to a user, when the host system detects the 
attachment of the device. 

5 FIG. 7 is a flow diagram illustrating a method of directed delivery of 

information to a user, in accordance with one or more aspects of the invention. As 
described in further detail above, when a device 120 is attached to host 1 10, client 
software 322(a) running on host 110 is notified of the attachment of device 120. 
At step 710, client software 322(a) queries device 120 for its device descriptor and 
0 collects information such as device class, device protocol, vendor identification 
number, and other relevant information to identify device 120 and its requirements. 
Client software 322(a) includes the device specific information in addition to host 
specific information, such as the operating system running on the host and other 
system software and hardware specifications in a communication packet and 
forwards it to server software 322(b) running on server system 130. 

Server system 130 includes database 140 wherein bodies of information or 
references to bodies of information related to various devices or other systems are 
stored in a structured manner. For example, in one embodiment of the invention, 
database 140 is a relational database with multiple links implemented across a 
distributed information system on the Internet. Upon receiving host and device 
specific information, server software 322(b) at step 730 searches database 140 for 
any information that can be associated with the device and host specific 
information forwarded by client software 322(a). The type of information that 
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server software 332(b) may search for includes, for example, promotional or 
educational material related to products and services associated with device 120 or 
host 1 10. The information may be presented in various formats including but not 
limited to text, pictures, movies, or interactive multimedia applications. 

By way of example, if device 120 is a Sony® digital camera attached to 
host 110, a Visor™ manufactured by Handspring Corporation, then the related 
information stored in database 140 may include information relating to photo 
processing mechanisms, hardware and software accessories for the digital camera 
or the Visor, other products manufactured by Sony or Handspring, other digital 
cameras or handheld computing devices, or references to on-line resources where 
additional information about the above products, services, or corporations can be 
found. Server software 322(b) searches database 140 based on the device and host 
specific information (e.g., device manufacturer, host operating system, etc.) 
forwarded to it by client software 322(a). The search results are presented to a user 
by launching a web browser or a special software application in response to the 
user selecting a hypertext or hyperlink, for example. 

Once presentation data in database 140 is identified, at step 740, server 
software 322(b) selects the most relevant data and form of presentation for delivery 
to host 110. In embodiments of the invention, presentation data selected for 
delivery to a user can be selected or forwarded in a predetermined order, based on 
demographics or profiles collected about the user, or other factors. In 
embodiments of the invention, client software 322(a) may be implemented to 
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monitor a user's interaction with host 110 to determine the types of applications 
the user deploys on host 1 10 and to formulate an interest profile for the user. If the 
user installs and/or plays a game of golf on his PDA, for example, then client 
software 322(a) may send a request to server software 322(b) indicating that the 
user's area of interest includes golf. In response, server 322(b) will search 
database 140 for data relating to game of golf, such as information about upcoming 
events and golf accessories available for sale. 

In accordance with one aspect of the invention, once server software 322(b) 
has identified the presentation data, then the data is formatted with respect to 
limitations and requirements of host 110 and device 120. The formatting 
requirements, depend, among other factors, on the bandwidth and graphic display 
capabilities of host 1 10. For example, if host 1 10 is a portable computer then data 
can be forwarded in a format suitable for display on a monitor that supports a VGA 
640x480 resolution. Otherwise, if host 1 10 is a wireless telephone then the display 
data may have to be adjusted for a different resolution suitable for display on the 
wireless telephone. The above formatting requirements, typically, relate to 
limitation in both hardware and software platforms in host 1 10. 

At step 750, server software 322(b) forwards formatted data to host 110. In 
embodiments of the invention, the step of formatting data to a meet the 
requirements of host takes place either before or after data is forwarded at step 750. 
If data is formatted prior to transmission then server software 322(b) performs the 
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task of reformatting the data. Otherwise, client software 322(a) will analyze and 
reconfigure the data into a display format compatible with host 120's requirements. 

As suggested earlier, forwarded data is displayed to a user some time after 
the attachment of device 120 to host 1 10. The data may be stored on host 1 10 and 
be redisplayed to the user at a later time, as well. In embodiments of the invention, 
display of data may be associated with a fee based service, where a third party can 
promote a service, product, or idea by subscribing to a service provider that 
provides the on-line services described in this application. 

It should be understood that system configurations are disclosed here by 
way of example. Other system architectures, platforms, and implementations that 
can support various aspects of the invention may be utilized. Thus, a system and 
method for configuring a host to recognize and communicate with a peripheral 
device is described in conjunction with one or more specific embodiments. These 
and various other adaptations and combinations of features of the embodiments 
disclosed are within the scope of the invention. The invention is defined by the 
claims and their full scope of equivalents. 
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